Computer systems and applications have reached almost every market on a global scale. As a result, vast sums of money are spent in researching and developing new applications and programs. Typically, these applications are written in a computer language selected by a software developer or by a group of software developers.
A trend among software developers has been toward use of object-oriented programming (“OOP”) languages. Three major categories of OOP languages are (1) systems programming languages, which are generally unmanaged and natively compiled and, in turn, executed natively; (2) productivity-oriented business application programming languages, which are generally managed and compiled to non-native bytecodes or a non-native intermediate language (“IL”) and, in turn, executed non-natively by a managed runtime environment or virtual machine; and (3) scripting languages, which are generally managed and expressed in plain text source code instead of a binary form like compiled languages, and, in turn, plain text source code is executed non-natively by a scripting runtime environment or virtual machine.
Scripting languages are relatively easy-to-program computer languages that use simpler and more permissive forms of expression than compiled languages, such as Java and C++. Scripting language programs are usually expressed in plain text as source code instead of a binary form like compiled programs, which makes them very readable and easy to modify. They are generally interpreted instead of being explicitly compiled by the programmer. This means that programmers see immediate results from their programming statements and makes for a very interactive development experience. These features make scripting languages well suited for beginners, experimentation and research, system administrative tasks, and high-productivity, fast-turn-around development projects. Scripting languages are becoming dominant in Web programming, both for Web server and Web client programming. Scripting languages are also used in, for example, Adobe Flash, integrated runtime environments from Adobe, Microsoft, and Sun, desktop operating environments like Mac OS X, as well as mobile devices, such as for example, but not limited to, the iPhone® that runs iOS, and the various Android devices that run Android OS. The mobile devices would also include tablet devices, such as for example, but not limited to, the iPad® that runs iOS, or the Google Nexus® and Samsung Galaxy® that run Google's Android OS. For these reasons, scripting languages are very popular with programmers and the range of devices that supports them continues to grow.
Systems programming languages are typically used for developing performance critical applications, operating systems, operating environments, operating system specific applications, managed runtime environments and virtual machines, embedded systems, and hardware specific software, such as for instance, device drivers. Systems programming languages are generally lower-level languages which offer finer control over the run-time execution of applications. Systems programming languages include, for instance but are not limited to C and C++.
Productivity-oriented business application languages are typically used for developing applications for electronic commerce, wireless devices, multimedia devices and platforms, accessing databases, web applications, and other business-related needs. Productivity-oriented business application languages are generally higher-level languages which offer greater programmer productivity and increased reliability during the run-time execution of applications. Business application languages include, for instance but are not limited to Java® and C# (pronounced, “C-Sharp”). These however, are just a few of the many OOP languages that may be utilized in generating applications.
Traditionally, software developers choose one computer language for systems programming and another for business applications programming. In doing so, however, they must make sacrifices and accept the tradeoffs of the selected language. The application, design methodology, and business model may all factor into the choice of programming language used for a particular application.
For instance, C++ is typically viewed as an advantageous language for creating large-scale applications, whereas Java is typically viewed as optimized for the distribution of program objects in a network such as the Internet. Java is generally considered a higher level language than C++, that is, closer to the actual business application. As a result, many programmers prefer to write programs in Java because it is generally considered an easier language to use than C++.
Another advantage Java provides is that Java objects cannot contain references to data external to themselves or other known objects. This ensures that an instruction input by a programmer cannot contain an address of data storage in another application or in the operating system itself, either of which could cause the program and possibly even the operating system to terminate or crash. In addition, Java utilizes a virtual machine that makes a number of checks on each object to ensure integrity. This results in a finished application that is not prone to low-level memory errors and requires considerably less debugging. C++ on the other hand does not have these safety functions such that a programmer may inadvertently or maliciously cause problems with the operating system. In addition, many of the computer viruses seen today exploit this characteristic of C++ to cause widespread computer problems. Many of these problems could be avoided by utilizing Java because of the built-in safety checks and balances inherent to the language.
Alternatively, there are some distinct advantages associated with C++ as opposed to Java. For instance, C++ is generally considered a higher performance language than Java. Once an application is written in C++, it may be compiled to native code or machine code, as opposed to Java, which is typically compiled into bytecode. As a result, unlike Java, a program compiled into native code does not need to operate with a virtual machine, which results in increased application performance. Another advantage to compiling a program to native code is that it is very difficult to derive the C++ source code from the native code, whereas it is a fairly simple matter to derive the Java source code from the compiled bytecode. Therefore, C++ can provide greater protection for a company's intellectual property.
In view of the forgoing, there is an inherent tension between using Java and using C++. Many programmers would prefer to write programs in Java, however many companies want their end product to be completed in C++ so that it may be compiled into native code. However, companies also recognize the benefits of using Java, realizing that it may be a faster and less expensive way to get new products and services to market. This is because Java is generally considered an easier language to use and also because of the greatly reduced debugging time associated with new applications.
Historically it has been very difficult or nearly impossible to convert a program written in C++ to Java and/or vice versa. To do so requires manual porting, which is generally labor intensive, error prone, and requires extensive re-testing.
To address these issues and minimize the differences between computer languages, a number of existing systems have tried a number of approaches. These include for instance: (1) cross-language interoperability layers and object mapping mechanisms; (2) native compilers for traditionally non-natively compiled languages; (3) programs which convert or migrate computer programs from one language to another language; and (4) programs which translate computer programs between different computer languages. None of these approaches, however, have provided an acceptable solution.
For instance, one approach taken is cross-language interoperability layers and object mapping mechanisms including the Sun Microsystems® Java Native Interface™ (JNI), the Microsoft® Common Object Model™ (COM), and the Object Management Group® (OMG) Common Object Request Broker Architecture™ (CORBA). Such solutions are generally suited for integrating two or more different computer languages and operating environments. However, they do not eliminate the need for middleware, such as virtual machines, managed runtime environments, and object request brokers (ORBs), but instead increase dependence on these. This dependence make these solutions unsuitable for demanding low-level systems programming for developing for instance, operating systems, virtual machines, and embedded systems.
A second approach taken includes native compilers for traditionally non-natively compiled languages including, for instance, the GNU® Compiler for Java (GCJ) and the Excelsior JET. The GNU Compiler for Java (GCJ) is a free (open source) software project and is disclosed in U.S. Pat. No. 6,110,226. These products compile Java source code or Java bytecode, a platform-independent intermediate language, to native binary executables. The GCJ compiler may generate native binary executables, which do not require a virtual machine to execute program, so long as the compiled Java program does not make use of Java classes or objects, which are externally referenced or otherwise not natively compiled. In the latter case, the compiled native binary executable requires an internal (statically-linked) or external (dynamically-linked) virtual machine, which suffers from the same drawbacks as cross-language interoperability layers and object mapping mechanisms. Alternatively, Excelsior JET for instance, generates native binary executables that generally depend on the presence of a virtual machine on the client system in order to run. However, these requirements carry the same drawbacks as common cross-language interoperability layers and therefore negate most of the benefits of native compilers.
While the GCJ compiler does support interoperability with C++ through CNI (Cygnus® Native Interface), this means of interoperability however, is effectively limited to the GNU C++ compiler. GCJ does not support interoperability with leading platform-specific C++ compilers, such as Microsoft Visual C++® for Microsoft Windows® operating system, nor does it support the industry-standard JNI to interoperate with leading Java virtual machines. Additionally, native compilers do not translate source code to another computer language, so they do not inherently benefit from wealth of available software development tools, such as compilers, linkers, optimizers, and debuggers, or features of other popular computer languages, such as C++.
A third approach has been to convert or migrate source code in one computer language to another computer language. This approach is disclosed in U.S. Pat. No. 6,453,464 (“the '464 patent”). This approach is directed toward migrating source code from an aging computer language, such as for instance COBOL, to an OOP language, such as Java. However, the resulting translated source code does not fully preserve the style and spirit of the original source code, is not easily human-readable, and does not support translation back to the original language. Therefore, the system disclosed in the '464 patent cannot be used for bi-directional translation between OOP languages to combine the best features of both languages.
A fourth approach taken has included computer language-to-computer language translation. Existing translators include Toba, C2J, and J2C, among others. These solutions, however, have severe limitations of their respective design and implementation. For instance, they fail to: manage objects exactly like the original language, manage arrays exactly like the original language, maintain the same high-level of thread safety characteristic in the original language, and support the full breadth of features of the original language. Additionally, none of these approaches support nor addresses bi-directional translation. Still further, these one-way translation approaches generally require translation of the entire application at one time, rather than providing for translation of only a file or a portion of a file.
Most modern scripting languages support Object-Oriented Programming (OOP) features. Such object-oriented scripting languages include, but are not limited to, JavaScript, Ruby, Python, Perl and PHP. Object-oriented programming features make such scripting languages easier to understand and their programs more maintainable. Further, to assist programmers, modern object-oriented programming languages have their own language-specific API class library.
However, not all the world's programmers are proficient in scripting languages and not all the world's devices support, or efficiently support, scripting languages. For example, a developer proficient in C++ or Java may prefer to run an existing C++ or Java program in a scripting environment. To do so, the developer would need to become proficient in the target scripting language and its associated API class library and would need to manually rewrite the existing C++ or Java program in the target scripting language. As another example, a developer proficient in a certain scripting language, such as JavaScript, Python, Ruby, Perl or PHP, would need to rewrite the program in C++ in order to run on an embedded or mobile device that did not support scripting languages.
Further, not all scripting languages are supported on all devices that support scripting. For example, Web browsers generally only support JavaScript and not Ruby, Python, Perl or PHP. Still further, a developer may need to produce a program that runs at peak efficiency on a device. Even though the device supports scripting languages, in order to perform at maximum speed and efficiency, the program must instead use a compiled programming language, such as C++. In this example, the developer would need to be proficient in C++ and either create or rewrite the program in C++ in order to meet the project requirements.
Further, there is a vast amount of source code, especially open source programs, readily or freely available on the Internet and through various other forms of distribution, such as CD-ROM and DVD-ROM. However, usually an individual program is only available for one particular computer language or perhaps a few computer languages. It is common for software developers to come across source code, especially by searching the Internet or by examining public source code repositories, which meet their needs except that the source code they have found is in a different computer language than their project requires. Such developers are faced with either manually porting the source code to their target computer language or limit their search results to only source code in their target computer language, neither option being desirable.
Further, for various business and technical reasons, certain devices will lack support for a particular scripting language and scripting runtime environment. The ability to add support for a particular scripting language and scripting runtime environment would be a desirable feature for consumers and vendors alike, especially if the feature could be provided entirely in software without requiring any hardware modifications. For example, the lack of support for Adobe Flash and its associated scripting language ActionScript on the iPhone has been a cause for complaint on the part of present and prospective iPhone user alike. At present, the wide range of Adobe Flash and ActionScript language programs are not available to iPhone users.
Further, the inherent nature of scripting language programs being expressed in plain text source code is highly undesirable for certain applications and certain organizations. In order to safeguard intellectual property, preserve trade secrets, and prevent tampering, especially related to computer security, online crime, and circumventing protection schemes for digital media, it would be essential that certain applications only be distributed in compiled binary form. This would either preclude scripting languages for such applications, or it would necessitate manually porting existing scripting language programs to a compiled language before being externally distributed.
For these reasons, it is desirable for an invention to automatically translate source code from an object-oriented scripting language to a compiled object-oriented programming language.
In line with this, it is further desirable to seamlessly and automatically translate a program at runtime, such as during the process of downloading and starting the program, from a foreign, or unsupported, object-oriented scripting language to a scripting language for which the host device includes built-in support.
Further, it is desirable for an invention to automatically translate source code from a compiled object-oriented programming language to an object-oriented scripting language.
Still further, is desirable for an invention to automatically translate source code from an object-oriented scripting language to another object-oriented scripting language.
It is further desired to provide a computer language translation system that may be coupled with associated software libraries and accurately and reliably translate source codes between higher-level productivity-oriented business application programming languages and systems programming languages.
It is still further desired to provide a bi-directional computer language translation system that may accurately and reliably translate source code from a higher-level productivity-oriented business application programming language to a systems programming language and back again.
It is yet further desired to provide a computer language translation system that is usable with multiple computing platforms, operating systems, and operating environments.
It is also desired to provide a computer language translation system that provides deterministic automated object management without a garbage collector in order to be suitable for embedded systems.
It is still further desired to provide a computer language translation system that may utilize industry-standard compiler tools, such as for instance, ANSI® C++ compilers.
It is yet further desired to provide a computer language translation system that will be virtual machine agnostic, specifically, that will be able to operate without a virtual machine, or conversely, if desired, able to interoperate with an industry standard virtual machine.
It is still further desired to provide a computer language translation system that adheres to industry standards for cross-language interoperability, such as JNI for interoperability between Java environments and C++ environments.
It is also desired to provide a computer language translation system that can be utilized by an Internet or Intranet search engine in order to automatically translate search results comprising source code from the original computer language of the found source code to the preferred computer language of the user requesting the search.
It is also desired to provide a computer language translation system that can be utilized by the search indexing engine of an Internet or Intranet search engine. As the search indexing engine comes across source code, the search indexing engine can use the invention to automatically translate source code from the original computer language of the source code to a multiplicity of computer languages, and then index the source code in its original computer language as well as a multiplicity of computer languages. This would allow the search engine to find more code sample in diverse computer languages regardless of the computer language of the search query itself.
It is yet further desired to provide a computer language translation system that may be utilized to translate only a portion of the source code to be translated.